如果整個 Region 掛了該怎辦？

前一天我們比過兩種擺法，最後推薦的是把兩台主機分開放在兩個 AZ，也就是下圖的方案乙：東京 Region 裡有兩台 EC2 主機，Web 1 在 AZ 1、Web 2 在 AZ 2。

今天我們拿方案乙做一次演練，在AWS 的白皮書，它提到啊，大部分常見的災害應該只會影響一個 AZ

比較少見的大範圍災害，或是 Region 裡的服務本身出了問題，影響就可能不只一個 AZ。

AWS 也有一個公開的事件摘要頁，裡面列了幾次以 Region 為單位描述的服務事件，讓你知道他們確實曾經發生過這類事情(抖抖

我們就趁這個機會來演練看看情境，圈起來整個東京 Region。AZ 1、AZ 2，還有東京其他的 AZ，全部都在圈內。

方案乙的 Web 1、Web 2 雖然分在兩個 AZ，但這兩個 AZ 都在東京 Region 裡，會一起受影響，沒有留下正常的主機。

大阪 Region 多開的一台 EC2 主機。它上面還沒程式也沒資料，暫時先叫它空白主機

每個 Region 在設計上都和其他 Region 隔開。所以想躲開「整個東京 Region 不能用」這種事件，東西就得放到東京以外的 Region。

這演練就呼應到我們的標題：分在兩個 AZ，擋不住整個 Region 不能用。

會提出這個細節，只是想呼籲讀者，你可能還有這個考量需要留意

那如果在大阪放一台主機，就算準備好了嗎？

在做防災演練的時候，我們會評估一個網站能在說好的時間內恢復服務，少掉的資料也在能接受的範圍內。這取決於你和合作廠商訂定契約時來定，有可能是 30 分內修復好、60 分鐘內修復好

以前在做政府專案時，保固合約有時候也會提到，必須得在 48 hr 內修復好，不然就會有罰金

但是越賺錢的平台，所要求的災害復原速度可能就要更快，畢竟每分每秒都是摳摳

那再回到主機，大阪那台空白主機目前位置在範圍外

要做到足夠的復原，至少得先有三樣東西：

1. 能在大阪跑的後端程式和設定：Web 1、Web 2 上跑的那份後端程式，要能在大阪的主機上跑起來。
2. 事先放在大阪、而且讀得到的資料備份：像是會員資料、報名紀錄。「讀得到」是指備份完整、拿得出來，真的可以拿來還原。
3. 演練過的切換：使用者的請求，要能改送到大阪的主機，而且真的試過。

這三條算是基本條件，除此之外同時也要進行災害復原時間的確認

因為大阪的主機不一定要一直開著，也可以等出事再開；所以像是開機、部署程式花的時間，都得算進恢復花的時間~

AWS 另一份講出事後怎麼把服務救回來的白皮書也有提到：除了資料外，程式和設定也要能在用來復原的 Region 重新部署；而且這套復原方式要定期測試，才是真的 ok。

演練做完，怎麼知道算不算過關？

「服務最後有恢復，就算過關吧？」

天下哪有那麼好康的事情(欸

大部分來說會有兩個上限：

• 服務最晚多久要恢復：從出事到服務恢復，最多能等多久。
• 最多能接受少掉多久的資料：還原回來的資料，最多只能停在出事前多久。

舉個例子。備份每 1 小時做一次，最後一次在 10:00，結果 10:50 東京出事了。

用 10:00 的備份還原，10:00 到 10:50 之間的新報名就不見了，這就是「資料少掉 50 分鐘」。

演練完，會量到兩個對應的數字：恢復花了多久、資料少掉多久。兩個數字要各自對照自己的上限。

延續這例子，假設這次演練的結果是這樣：

恢復花了 40 分鐘，在 1 小時內，這項過關；資料少掉 50 分鐘，超過 30 分鐘的上限，這項就沒過。

這裡有幾個很常見的誤會：

• 把兩個數字加起來：「40 加 50 是 90 分鐘，兩項都不過。」兩個數字量的是不同的事，一個是服務停多久，一個是資料少多少，自然是不能相加。
• 用一項抵另一項：「恢復得很快，資料少一點沒關係吧？」一項過關，不代表能抵銷另一項沒過。所以要思考的是資料備份的做法：例如每 1 小時才備份一次，運氣不好時就可能少掉快 1 小時，就很難保證只少掉 30 分鐘。

所以上限要事先跟廠商跟團隊說清楚，醜話先說在前頭，並分享目前的機制是如何，費用是否可以接受，才能確保雙方能達成共識

放兩個 AZ 就好，還是要跨 Region？

讀到這裡，你可能會想：「那到底什麼時候放兩個 AZ 就夠，什麼時候才要跨 Region？」

雖然我很想說廠商有錢，跨 Region 當然最好 XD (誤

不過還是有些判斷的順序，要看網站能不能接受停下來。例如有了兩個上限，再加上費用，就能把這件事用這個切角來規劃看看

先把兩種做法放在一起比

費用試算：一個月大概差多少？

光說「比較多」還是很模糊，用一個簡單的假設算算看看：

• 主機都是 EC2，規格用 t4g.micro（EC2 的一種小型規格），Linux，隨用隨付（開多久算多久），一個月開 730 小時
• 備份資料有 20 GB
• 跨 Region 時，大阪也存一份 20 GB 的備份；每天把變動的 1 GB 複製過去，一個月大約傳 30 GB

用到的單價是主機東京每小時 US$0.0108

大阪每小時 US$0.0109

備份存放東京、大阪都是每 GB 每月 US$0.05；從東京傳資料到大阪，每 GB US$0.09

像是有的時候，廠商出一張嘴希望災害演練還原可以更完善時

拿出這種報表讓廠商評估，也正是雲端工程師的工作內容之一，畢竟真正看到金額，就會更審慎評估多出來的摳摳，以及預期會額外花多少時間，畢竟也需要定時去做災房演練~

那到底怎麼選？

我會建議先問自己三個問題：

1. 你怕的是哪一種事件？ 怕的是一台主機壞掉、一個 AZ 出事，放兩個 AZ 就擋得住。要擋整個 Region 出事，才需要跨 Region
2. 整個 Region 真的出事時，網站能不能等？ 這種事很少見，但一發生可能要等好幾個小時哭哭。像 AWS 公開的事件摘要裡，2021 年 12 月 7 日美國維吉尼亞北部 Region 的事件，從太平洋時間早上 7:30 開始，到下午 2:22 網路設備才全部恢復，中間好幾個服務在建立、管理資源時都受到影響。如果網站停這麼久還能接受，放兩個 AZ 通常就夠；假使停一個小時就損失很大，才值得考慮跨 Region。
3. 多花的錢和力氣，划不划算？ AWS 的白皮書提到，在同一個 Region 用多個 AZ，其實就足夠應付大部分需要防的狀況；如果復原方案的花費比出事造成的損失還高，除非有法規之類的要求，不然就不一定要做。

下面就整理成一張表：

最後分享一下我們公司的做法：目前只有放在同一個 Region 的兩個 AZ，沒有做跨 Region，主因是我們是學習系統，而非高頻的電商平台，用 AZ 有跨資料中心我們認為就很足夠，就沒跨 Region。但判斷標準建議還是以上表為主

小結

最後小結一下~

下次聽到「我們已經做了跨 AZ，很安全」，或是「我們有跨 Region，很安全」

如果你還想更進階問細節的話，或許你還能問：

1. 我們擔心的事件，影響範圍有多大？
2. 放在範圍外的東西，出事時真的用得上嗎？
3. 網站最晚多久要恢復、最多能少掉多久的資料，為了做到，平常願意額外準備多少時間？

希望這篇文章，有助於你對 Region 跟 AZ 有更深入的瞭解，我們下回見 :D